1. The Field of the Invention
The present invention relates to font rendering technology; and more specifically, to mechanisms for performing algorithmic simulated emboldening of font characters.
2. Background and Related Art
Computing technology enables a wide-variety of applications. Some of these applications interface with human beings by receiving input from a human user via, for example, a mouse, keyboard, microphone, camera, or the like, or by providing output to a human user via, for example, a speaker, display or printer. In particular, since sight is such a dominant human sensory capability, human users typically rely on some sort of printer or display in order to interpret computational results and/or to interface with an application.
One type of displayed material is characters. Sets of characters (whether it be text or otherwise) may often be logically grouped together. A font represents an example of a logical grouping of characters. In particular, a font is a set of printable or displayable characters in a specific style and size. The characters of the font are often termed “glyphs”.
Characters (glyphs) of a font can be described by outlines or by embedded bitmaps. An outline describes the character by describing the contours of the character shape. Such outlines are more easily scalable. During the rasterization process, software may convert the outline into a bitmap that is suitable for display given the desired point size or Pixels Per EM (ppem).
Embedded bitmaps are usually manually pre-designed bitmap images that correspond to specific ppems. Embedded bitmaps usually are present only for low and middle ppems and for those ppems that usually require higher image quality than those that result from rasterization of unhinted outlines. Hinting is a conditional modification of the outlines which presents another way (compared to embedding bitmaps) of improving quality of the rendered results for low ppems.
Traditionally, characters in fonts with relatively small numbers of characters and relatively simple character shapes (such as Latin) are described by hinted outlines. On the other hand, characters in fonts with a large number of characters and relatively complex character shapes (such as East Asian fonts, hereinafter also referred to as EA) are described by unhinted outlines and usually by a series of embedded Black and White bitmaps (hereinafter also referred to as BW). Those more complex fonts usually have embedded bitmaps for some, but not necessarily all, low and middle ppems. Furthermore, the embedded bitmaps do not necessarily cover the full repertoire of the characters in the font. Very rarely, fonts contain Anti-Aliasing (AA) embedded bitmaps. Very few, if any, fonts contain embedded bitmaps in CLEARTYPE ® (hereinafter referred to as CT) format.
In some circumstances, it is desirable to “bold” characters. Bolded characters tend to have a heavier visual and typographic weight. Bolded characters are often provided in place of their counterpart regular weight characters. There are a number of instances in which it may be desirable to bold characters. For example, characters are often bolded to emphasize the meaning conveyed by the characters.
A font has a true bold version if there are separate designs of the font characters representing heavier weight and those designs are stored in a way recognizable by the rendering software as being associated with the original font. True bold designs associated with characters of a font do not necessarily follow a uniform bolding transformation with respect to the characters of the original regular weight font. Different elements of the characters are emboldened in the different ways, as appropriate, given the unique form of the character. Often, a human being is involved with the custom design of bolded fonts so as to take into account a host of subjective aesthetic judgments that contribute to a more authentic high quality bolded look.
Traditionally, most commonly-used fonts with smaller numbers of characters and relatively simple character shapes (such as Latin fonts) have associated true bold versions. However, due to the time and cost associated with custom design of fonts, most of the bigger fonts with more complicated characters and larger numbers of characters do not have associated true bold versions. Furthermore, the design of such true bold fonts for these complex character sets can be prohibitively expensive. As a result, if a user chooses a bold option, a simulated emboldening is executed by a rendering engine.
Simulated emboldening is an automatic, algorithmic procedure performed by a rendering engine based on the data from the regular font. Currently applied simulated emboldening is performed by a uniform algorithm that is not always sensitive to the original design intent or to the numerous subjective judgments that improve the quality and appearance of the bolded font data.
Although currently applied simulated emboldening algorithms for simulated emboldening provide quite legible results for the fonts with simpler characters, such algorithms usually fail to provide legible results for the fonts with more complex and dense characters.
In a simplified view, the rendering process may be divided into three stages. In the first stage, information from the font file is accessed and, if needed, translated into a rasterizer-readable format. In the second stage, the rasterization process occurs in which the rasterizer-readable font format is converted into a two dimensional-array of values called a bitmap. The bitmap will have one value per pixel for a “simple bitmap”, and more than one value per pixel for an “overscaled bitmap” as is the case for a CLEARTYPE ® bitmap. The value may be a simply binary value (e.g., a zero or a one) for a Black and White (BW) bitmap, or a range of values (e.g., from 0to 16) for an AA bitmap. In the third stage, the actual mapping of the bitmap values to the pixels (or pixel sub-components) of the display occurs resulting in the character being displayed.
Simulated emboldening happens at the second stage during the rasterization process. Although the third stage of mapping the bitmap values to the display may influence the choice of a particular emboldening algorithm and/or tuning the parameters once an algorithm is chosen, particular kinds of mappings can be omitted from the description for clarity in describing the basic principles and embodiments of the present invention. As simulated emboldening algorithms occur during the second stage of rasterization process, the second stage processing will be the primary stage that is discussed herein.
Currently, there are three primary rendering modes; namely, Black and White (BW), Anti-Aliasing (AA) and CLEARTYPE ® (CT). Conventionally, at the rasterization stage, the rendering mode defines the final format of the bitmaps and, in particular, the output format of the emboldened bitmaps if emboldening is applied.
There are a variety of factors that may influence a choice of the rendering mode. Such factors may include, for example, device properties and settings, requested ppem, font data (for example, presence of the embedded bitmaps, presence and content of the “gasp” table (as in an OPENTYPE ® /TrueType font file)), presence and kind of any geometrical transformation requested. Other factors can influence the choice of the rendering mode. For example, the “complexity” of the font may be considered in choosing the rendering mode. For example, it may be decided to apply BW rendering mode and make use of embedded BW bitmaps for relatively complex fonts and apply CT rendering mode and completely ignore embedded BW bitmaps for relatively less complex fonts.
The choice of rendering mode does not necessary fully realize all the possibilities of the display device. In many situations, the choice is made by software and is based on the general experience of the different rendering modes being more or less legible for the human eyes under different conditions. For example, at low ppem, the AA rendering mode usually provides lower quality rendering results than the BW mode, especially if a font contains BW embedded bitmaps. Therefore, a flag in the “gasp” table can force the BW rendering mode to be applied when rendering low ppem characters, even though the great majority of the display devices can display shades of gray. The same is true regarding CLEARTYPE ®. For example, it might be decided to apply BW rendering mode for relatively complex fonts at lower ppems where the embedded BW bitmaps are present in the font, even though the display device has the capability to render in CT mode. The selected rendering mode should provide the best user experience, and can be changed if another rendering mode appears to provide better rendering results.
Currently, regular weight and bold weight characters are commonly rendered in the same rendering mode assuming that all other conditions are the same. However, this decision does not reflect any internal requirements and can be overwritten if another approach will be shown to produce better rendering results.
Current algorithms for bitmap emboldening commonly use the same types of bitmaps for input and output, which means that for an emboldening algorithm, the rendering mode currently implicitly establishes both input and output types. However this dependency is not generically necessary.
The rasterization process goes through the same major steps for the regular and the simulated bold weights. One difference is that if a form of simulated emboldening is applied, an additional emboldening step is used in the rasterization process. This emboldening step intercepts the flow of rasterization as it would be performed for a regular weight, performs necessary emboldening operations, and then lets the flow of the rasterization continue exactly as in the case of a regular weight. Therefore, there will now be some general background description of rasterization for the regular weight so that the emboldening step may be understood in its proper rasterization context.
A rasterizer might accept a lot of different parameters related to specific characteristics of a font or to different rendering conditions being requested. For the purpose of describing the conventional model of simulated emboldening, we will concentrate on the following input information given to a rasterizer:                Information regarding identification of a character being requested (for example a Unicode character code).        Information regarding rendering conditions such as size (ppem), presence of a non-identical geometrical transformation, request for simulated emboldening. If a simulated emboldening is requested, some additional parameters identifying “heaviness” (amount of emboldening) and direction of the emboldening will be passed to the rasterizer (described below in more detail).        Information coming from the font file: such as whether an embedded bitmap is present for a particular character or sum of the characters for the same conditions, access to the description of the embedded bitmap or/and the outline data for a specific character, information specified by designers such as a preferred rendering mode for particular ppems.        Information regarding the rendering mode (which defines the format of the resulting bitmap): specification of the rendering mode BW, AA or CT and any additional required information (for example, in the case of AA emboldening—requested number of gray levels).        
The rasterizer will perform appropriate rasterization based on the input information, and will provide a resulting bitmap in the format corresponding to the requested rendering mode, along with metric information related to the size and positioning of the resulting bitmap.
Since the new algorithms for the emboldening simulation described in the detailed description of the preferred embodiments section below are not intended to necessarily modify the metric information, the bitmap output of the conventional rasterization processes will now be described.
In CT rendering mode, fonts do not conventionally contain embedded bitmaps in the CT format. Therefore, rasterization in CT mode always starts from the outline data. There are two major stages of the CT rasterization process as illustrated in FIGS. 1A and 1B: “(CT: Outline to Overscaled Bitmap)” (see FIG. lA. with the first image (from left to right) comprising the Outline and the second image comprising the Overscaled Bitmap) and “(CT: Overscaled to Simple Bitmap)” (see FIG. 1B, with the images (from left to right) comprising an overscaled bitmap, a simple bitmap output, a simple bitmap with values reflecting filtering, and an image of possible mapping of cleartype values). The algorithm for computation of the overscaled bitmap based on the outline data used during stage (CT: Outline to Overscaled Bitmap) and the algorithm for computation of the final values of the simple CT bitmap during stage (CT: Overscaled to Simple Bitmap) do not depend one each other, and can be modified independently as long as they work with the required input and output formats.
Whichever approach is being used, the final output has the same format: simple CT bitmap. An important characteristic of this rasterization process is that it uses overscaled bitmap as an intermediate result of computation of the final output bitmap.
Now that the rasterization process has been described generally for the CT rendering mode, the description proceeds to conventional CT emboldening algorithms. Depending on the type of input, algorithms for the emboldening simulation are subdivided into two large groups: “bitmap emboldening” and “outline emboldening”. In addition to the various emboldening parameters, a bitmap. emboldening algorithm accepts a bitmap as its input, while an outline emboldening algorithm accepts an outline as its input. Bitmap emboldening returns a bitmap as its output, while outline emboldening returns a modified outline, which later will be scan-converted in order to produce a bitmap.
Bitmap and outline emboldening algorithms are applied at different stages of the rasterization process. Outline emboldening will be always applied before the first step of the rasterization process as it would be performed for a regular weight. After an outline emboldening is performed, the rasterization will continue exactly as it would in the case of a regular weight.
Currently, outline emboldening is almost never applied. Bitmap emboldening is performed by most of the applications in most situations, except in the rare cases when a non-trivial geometrical transformation is applied to a text. The capability of applying bitmap emboldening does not depend on the character having an embedded bitmap. Bitmap emboldening can thus be applied to characters that either have, or do not have, an embedded bitmap. If the character does not have an embedded bitmap for the requested condition, the result of scan-conversion based on the outline information will serve as an input for a bitmap emboldening algorithm. The principles of the present invention apply more to bitmap emboldening and thus several conventional bitmap emboldening algorithms will now be described.
By definition, bitmap emboldening algorithms accept bitmaps as their input and return bitmaps as their output. In addition to the bitmap itself, a bitmap emboldening algorithm usually accepts information regarding heaviness and direction of emboldening. This information can be expressed by a pair of “emboldening shifts” in the horizontal and vertical directions respectively. An emboldening shift identifies by which amount (expressed in pixels) an emboldened bitmap should be visually heavier than the original one and a sign of a shift shows the direction (to the right/to the left and to the top/to the bottom) of the emboldening. Most of the current applications work with emboldening shifts corresponding to whole numbers of pixels only. In addition, at low/middle and even at the lower range of high ppems (e.g., up to about 50 ppem), simulated emboldening by 1 pixel to the right (and 0 pixels in the vertical direction) is usually applied.
The input bitmap can originate from different data (such as embedded bitmap or a glyph's outline) and can be computed in different ways. The particular way the input bitmap is computed is irrelevant for the emboldening algorithm that is applied to the bitmap. What matters is which format of an input bitmap is expected by an emboldening algorithm and which format of an output bitmap the algorithm will generate. The various emboldening algorithms will thus be distinguished based on the format of the input and output bitmaps.
Different kinds of bitmap emboldening algorithms can be applied at different steps of the rasterization process since different steps of the rasterization process work with bitmaps in different formats. However currently applied bitmap emboldening algorithms often start with simple bitmaps (in BW, AA or CT format) and generate simple bitmaps in the same format as their input.
Most of the currently applied bitmap emboldening algorithms work with simple bitmaps both as input and output, even during a rasterization process that involves computation of overscaled bitmaps. If overscaled bitmaps are computed, emboldening is applied after the overscaled bitmap is converted into a simple bitmap.
In addition, most of the currently applied bitmap emboldening algorithms have exactly the same output bitmap format as the input bitmap format.
Furthermore, the algorithms often turn on or make darker some of the pixels that were off or had lighter colors in the input bitmap, and often do not turn off pixels or make them lighter.
Also, conventional algorithms typically decide whether to modify a value of a specific pixel based on the local characteristics of the input bitmap, such as one (for low/middle ppems) or several neighboring pixels in the direction of the emboldening. Currently used algorithms do not use information of the neighboring pixels in the direction perpendicular to the emboldening.
Moreover, conventional algorithms work row-by-row (for horizontal emboldening) and column-by-column (for vertical emboldening) and, therefore, the algorithms analyze only one direction (either horizontal or vertical) at a time. In other words, the resulting value of a pixel depends on neighbors of a pixel either in the row only or in the column only and does not take into account a two-dimensional neighborhood.
Currently applied bitmap emboldening algorithms can be applied in the horizontal or vertical direction. Algorithms for horizontal and vertical directions are essentially symmetric, with change of the directionality only. Generally, the algorithms for horizontal and vertical emboldening do not intermix. In other words, if the emboldening should be applied in both directions, it will first be applied in one direction and then applied in another direction to the result of the emboldening in the first direction.
Furthermore, besides the rectangular pixel area containing the input bitmap, the algorithms usually affect one or several rows and/or one or several columns adjacent to the rectangular area, depending on the values of the emboldening shifts accepted as the parameters.
For low/middle ppems (i.e., up to about 50 ppem), the algorithms usually apply emboldening by 1 pixel in the horizontal direction to the right. Note, that the low/middle ppems are exactly the area where the quality of the rendered images is especially challenging and where an improvement of the existing algorithms is especially required.
FIG. 2A illustrates the context of the conventional CT emboldening algorithm The conventional CT bitmap emboldening algorithm operates on a simple bitmap. The CT emboldening algorithm (referred to as “[Step 1A: Simple Subpixel Bitmap Regular to Simple Subpixel Bitmap Bold]” in FIGS. 2A and 2B) is applied as soon in the rasterization process as a simple bitmap becomes available. In other words, the CT emboldening algorithm is applied at the second stage (CT: Overscaled To Simple Bitmap) of the rasterization, between the first step [Step 1: Overscaled to Simple Subpixel Bitmap] and the second step [Step 2: Filtering] (see FIG. 1B).
Both the input and the output of the conventional CT emboldening algorithm are simple bitmaps in “subpixel” format, in which every value represents the cumulative numbers of subpixels of the different colors such as (Red, Green, Blue). The CT emboldening algorithm works according to an “additive” principle. The algorithm does not operate on exact positions of subpixels inside a pixel, but rather on the cumulative information regarding numbers of turned on subpixels.
Although the algorithm works with the cumulative values only, the results are quite similar to the simplest algorithm that would work directly on the overscaled bitmap, which provides a reasonable justification for the current algorithm. The problem is that the current algorithm often fails to produce legible results for more complex characters.
For emboldening by 1 pixel to the right, a conventional algorithm called hereinafter “<CT: Alg Standard>” works as follows:                For every row in the original bitmap, proceed from right to the left.        For every pixel:        
If left neighbor of the pixel has a non-zero value Vleft (i.e. has at least one  turned on subpixel in the overscaled bitmap){ If the pixel itself has a non-zero value (i.e. has at least one turned on   subpixel in the overscaled bitmap) {  Assign maximal value (corresponding to all subpixels turned on)  to the pixel } Else {  Assign value Vleft to the pixel }}
An example of application of the algorithm is shown in FIGS. 2B and 2C. This example continues from the description for the character “A” in the description of the CT rasterization process for a regular weight (compare to FIGS. 1A and 1B).
Accordingly, what would be advantageous are overscaled (e.g., CT) simulated emboldening mechanisms in which the emboldened character is more legible and readable, even for complex characters.